fix: redraw only the views whose moving pictures are due, at most 30 times a second - #49

Fixes #39

Cause

anim::frame_now scheduled each playing picture's next frame through anim::wake, and the wake's timer called window.refresh(). That dirties the whole window and sets GPUI's refreshing flag, which bypasses view caching. The only floor on frame time was frames::shown_for, which only slows frames of 10 ms or less, so a GIF with 16–20 ms frames redrew the whole window at about the display rate. The hover handler for hover-to-play pictures also called window.refresh().

Fix (crates/tinyclient/src/gui/anim.rs)

• Targeted notify. frame_now records the view drawing the picture (window.current_view()). The window's single timer keeps a per-view due time (Due<EntityId>). When it fires it redraws only the views that are due, then sets itself for the rest. Views that are not due, and any view embedded with .cached, are not drawn again.
• A floor of 33 ms per window, not per view. A playing picture asks to be drawn again no sooner than FASTEST (33 ms) after it was drawn, and the timer fires no sooner than FASTEST after it last fired for a view, whichever view asks. The window-level floor matters because no view is .cached yet, so every wake draws every view. Without it, a view kept its earlier due time even after another view's wake had already drawn it, and two pictures on different beats drew the window about 50 times a second with gaps as small as 3 ms. A view that is due is never dropped; it waits for the next slot, at most 33 ms. The frame shown is still worked out from elapsed time (frame_at), so a 20 ms GIF keeps its real speed and skips the frames in between.
• The root is refreshed, not notified. cx.notify(view) runs the view's observers, and window.refresh() never did. Shell is the window's root and paints hover-play avatars itself, so notifying it on every frame ran observe_self → follow_open and the Settings window's cx.observe(&shell, …). That meant an open Settings window redrew at up to 30 fps while an avatar animated. When the due view is the window's root (found with update_root in the timer), it is now drawn with window.refresh(). It is the same draw, but no observers run. The hover handler does the same. It is deferred with cx.defer until the window is let go, because only then can the root be told apart.
• Closed windows. A timer that fires after its window has closed now removes that window's entry from the wake map.

Not in this PR: .cached views

No GUI view uses .cached(...) yet. Until one does, GPUI still re-renders every uncached view when any view is dirty, so for now the CPU saving comes from the 30 fps window cap: about 1.6x fewer full draws for one 20 ms GIF, about 2x for 16 ms, and more with several pictures on different beats. The targeted notify is the groundwork that will let caching pay off later. Refreshing the root would also redraw cached children, but only when a picture the root paints itself is due.

I did not add .cached because it isn't safe yet. Several child views get state pushed into them during Shell::render without a notify. For example, MemberList::see assigns self.scene without notifying, so a cached view would show stale content. Caching MemberList, Composer and Pane needs those paths checked first, so it belongs in a follow-up.

Left as is: notifying a view that was released after it asked for a frame leaves an empty invalidator entry in GPUI. GPUI has no public way to check whether an EntityId is still alive, and this only happens once per released view.

Validation

• cargo test -p tinyclient --features gui: 351 passed, 0 failed, 1 ignored.
• cargo test -p tinyclient --features gui anim: 9 passed, 6 of them in anim.
• cargo test -p tinyclient (no gui): 12 passed, 0 failed.
• cargo clippy -p tinyclient --features gui --all-targets: no warnings in anim.rs. The warnings in other files are already on main.
• Unit tests. The scheduling is a pure struct (Due), and the tests drive it with an injected clock:
  • the_window_wakes_at_most_thirty_times_a_second_however_many_views_play simulates a window where every draw makes every view ask again. With two views on 20 ms and 45 ms beats, it draws 31 times in the first second, never closer than 33 ms. Every ask is met within 33 ms, and the timer goes idle once nothing asks. A 100 ms picture alone is still drawn every 100 ms. With the window floor removed, the same test fails with 52 draws and gaps of 3–33 ms, which matches the review's finding.
  • a_wake_draws_only_the_views_that_are_due checks that only due views are drawn, that the sooner ask wins, that the timer only moves sooner, that a firing with nothing due keeps the timer, that the floor holds the next fire, and that the timer goes idle and re-arms.
  • a_fast_animation_asks_no_sooner_than_fastest_and_keeps_its_time checks the per-ask floor, and that a 20 ms GIF skips frames by the clock.

Not verified: I did not run the app with animations playing, and did not profile CPU or frame rate live. The draw-rate figures come from the simulation above, not a measurement. TINYCLIENT_FRAMES=1 with the gui-shot feature can confirm it on a live session.

🤖 Generated with Claude Code